Configuring Call Admission Control

You can implement Call Admission Control (CAC) to regulate the volume of voice traffic handled by the device.

CAC configuration is done using two tables with parent-child type relationship:

■ Call Admission Control Profile table: This is the parent table, which defines a name for the CAC profile.
■ Call Admission Control Rule table: This is the child table, which defines the actual CAC rules for the profile.

You can configure up to 1,500 CAC profiles and up to 1,500 CAC rules. In addition, a CAC profile can be configured with up to 8 CAC rules.

Once you have configured a CAC profile with CAC rules, you need to assign it to any of the following SIP configuration entities (using the 'CAC Profile' parameter):

■ IP Group (see Configuring IP Groups)
■ SIP Interface (see Configuring SIP Interfaces)
■ SRD (see Configuring SRDs)

CAC rules define the maximum number of allowed concurrent calls (SIP dialog-initiating requests) for the assigned SIP entity (listed above) and per registered user belonging to the SIP entity. This can also include the maximum number of allowed concurrent SIP dialogs per second (rate). The CAC rule can be defined for a specific SIP message type (e.g., only INVITEs) as well as for a specific call direction (e.g., only outbound calls).

■ Token Bucket: This scheme is a SIP-dialog rate control using the token-bucket mechanism. Token bucket is a control mechanism that determines the rate of SIP dialog processing based on the presence of tokens in the bucket. Tokens in the bucket are removed ("cashed in") for the ability to process each dialog. If there are no tokens, the device rejects the dialog request with a SIP 480 (Temporarily Unavailable). Configuration of the token-bucket mechanism involves the following:
● Configuring the number of tokens that are added to the bucket per second. This is referred to as rate. To process (allow) a SIP dialog, the device needs a token from the bucket.
● Configuring the maximum number of tokens that the bucket can hold and thus, the maximum number of tokens that can be used for processing SIP dialogs that are received at one time. This is referred to as burst.

For example, assume that the rate is configured to 1 and the burst to 4:

● One token is added to the bucket every second.
● The maximum number of tokens that the bucket can hold is four.
● If SIP dialogs have never been received by the device, the bucket is filled to its maximum, which is four tokens (i.e., burst), regardless of the number of seconds that have passed.
● If four SIP dialogs are received at the same time (i.e., burst), the device uses the four tokens to process the dialogs. The bucket is now left with no tokens at that given moment, but after a second, a new token is added to the bucket (due to the rate). If there are no calls for the next three seconds, the bucket fills up again to four tokens (and no more).
● If the bucket contains four tokens (i.e., full) and five SIP dialogs are received at the same time, the device uses the four tokens to process four of the dialogs and rejects one.
● If the bucket has one token and SIP dialogs are then received every second, the device uses the token to process the first dialog, adds a token to the bucket after a second and processes the second dialog, and so on.

Your CAC rule can also define a guaranteed number of concurrent calls (reserved capacity) for the assigned SIP entity (see above) . Reserved capacity is especially useful when the device operates with multiple entities. For example, if the total call capacity supported by the device is 200, a scenario may arise where a SIP entity may reach 200 call sessions, leaving no available call resources for the other SIP entities. If the reserved call capacity of a SIP entity is threatened by a new call for a different SIP entity, the device rejects the call to safeguard the reserved capacity.

Requests that reach the user-defined call limit (maximum concurrent calls or call rate) are sent to an alternative route, if configured (in the IP-to-IP Routing table). If no alternative routing rule exists, the device rejects the SIP request with a SIP 480 "Temporarily Unavailable" response.

● If the device rejects an incoming SIP dialog request due to CAC, it sends a SIP 480 “Temporarily Unavailable” response.
● The device applies the CAC rule for the incoming leg immediately after the Classification process. If the call / request is rejected at this stage, no routing is performed. The enforcement for the outgoing leg is performed within each alternative route iteration. This is accessed from two places - during initial classification / routing and during alternative routing.
● CAC doesn't apply to Test Calls (see Configuring Basic Test Calls).

The following procedure describes how to configure CAC profiles through the Web interface. You can also configure them through other management interfaces:

■ Call Admission Control Profile table: ini file [SBCAdmissionProfile] or CLI (configure voip > sbc cac-profile)
■ Call Admission Control Rule table: ini file [SBCAdmissionRule] or CLI (configure voip > sbc cac-rule)
➢ To configure a CAC profile:
1. Open the Call Admission Control Profile table (Setup menu > Signaling & Media tab > SBC folder > Call Admission Control Profile).
2. Click New; the following dialog box appears:

3. Configure a CAC profile according to the parameters described in the table below.
4. Click Apply.

Call Admission Control Profile Table Parameter Description

Parameter

Description

'Index'

[Index]

Defines an index number for the new table row.

Note: Each row must be configured with a unique index.

'Name'

name

[Name]

Defines a descriptive name, which is used when associating the row in other tables.

The valid value is a string of up to 40 characters. By default, no value is defined.

Note:

■ The parameter value can't contain a forward slash (/).
■ The parameter value can't be configured with the character string "any" (upper or lower case).
5. In the Call Admission Control Profile table, select the required row, and then click the Call Admission Control Rule link located below the table; the Call Admission Control Rule table appears.
6. Click New; the following dialog box appears:

7. Configure a CAC rule according to the parameters described in the table below.
8. Click Apply.

Call Admission Control Rule Table Parameter Description

Parameter

Description
Match

'Index'

sbc-admission-rule-<Index>/<Index>

[SBCAdmissionRule_RuleIndex]

Defines an index number for the new table row.

Note: Each row must be configured with a unique index.

'Request Type'

request-type

[SBCAdmissionRule_RequestType]

Defines the type of SIP dialog-initiating request to which you want to apply the rule (not to subsequent requests, which can be of different type and direction).

■ [0] All (default)
■ [1] INVITE
■ [2] SUBSCRIBE
■ [3] Other = All SIP request types except INVITEs and SUBSCRIBEs (e.g., REGISTER).

'Request Direction'

request-direction

[SBCAdmissionRule_RequestDirection]

Defines the call direction of the SIP request to which the rule applies.

■ [0] Both = (Default) Rule applies to inbound and outbound SIP dialogs.
■ [1] Inbound = Rule applies only to inbound SIP dialogs.
■ [2] Outbound = Rule applies only to outbound SIP dialogs.

Action

'Limit'

limit

[SBCAdmissionRule_Limit]

Defines the maximum allowed number of concurrent SIP dialogs. You can also use the following special values:

■ [-1] -1 = (Default) Unlimited number of concurrent SIP dialogs.
■ [0] 0 = Blocks all the SIP dialog types specified in the 'Request Type' parameter (above).

Note: The parameter is not related to the rate-limiting algorithms.

'Limit per User'

limit-per-user

[SBCAdmissionRule_LimitPerUser]

Defines the maximum number of allowed concurrent SIP dialogs per user.

You can also use the following special values:

■ [-1] -1 = (Default) Unlimited number of concurrent SIP dialogs per user.
■ [0] 0 = Blocks all the SIP dialog types specified in the 'Request Type' parameter (above).

Note: The parameter is not related to the rate-limiting algorithms.

'Rate'

rate

[SBCAdmissionRule_Rate]
■ Token Bucket algorithm: Defines the number of tokens added to the token "bucket" per second, where a token "buys" a SIP dialog. For example, if you configure the parameter to 1, one token is added to the bucket every second. If there are no calls for five seconds, the bucket would have accumulated 5 tokens.

The valid value is 0 to 65,535. The default is 0 (i.e., unlimited rate).

Note:

■ If you configure the parameter, you must also configure the 'Maximum Burst' parameter to a non-zero value.

'Maximum Burst'

max-burst

[SBCAdmissionRule_MaxBurst]

Defines the maximum number of SIP dialogs that can be processed at any given time.

Token Bucket algorithm: In other words, it defines the maximum number of tokens that the "bucket" can hold. The device only accepts a SIP dialog if a token exists in the "bucket". Once the SIP dialog is accepted, a token is removed from the "bucket". If a SIP dialog is received by the device and the token "bucket" is empty, the device rejects the SIP dialog. Alternatively, if the "bucket" is full, for example, 100 tokens, and 101 SIP dialogs arrive (before another token is added to the "bucket", i.e., faster than that configured in the 'Rate' parameter), the device accepts the first 100 SIP dialogs and rejects the last one. Dropped requests are not counted in the "bucket".

The valid value is 0 to 65,535. The default is 0 (i.e., unlimited SIP dialogs).

Note:

■ The parameter functions together with the 'Rate' parameter (see above). Therefore, the parameter must be configuired.
■ The parameter's value cannot be greater than 10 times (x) the value of the 'Rate' parameter. For example, if you configured the 'Rate' parameter to 2, you can configure the 'Maximum Burst' parameter to any value less than or equal to 20 (i.e., 10 x 2).
■ The token bucket feature is per SIP request type and SIP request direction.

'Rate Per User'

rate-per-user

[SBCAdmissionRule_RatePerUser]

Defines the maximum allowed number of concurrent SIP dialogs per registered user that can be handled per second.

The valid value is 0 to 65,535. The default is 0 (i.e., unlimited rate).

Note:

■ If you configure this parameter, you must also configure the 'Maximum Burst per User' parameter to a non-zero value (see below).

'Maximum Burst Per User'

max-burst-per-user

[SBCAdmissionRule_MaxBurstPerUser]

Defines the maximum number of tokens (SIP dialogs) per user that the bucket can hold (see the 'Maximum Burst' parameter for a detailed description).

The valid value is 0 to 65,535. The default is 0 (i.e., unlimited SIP dialogs).

Note:

■ The parameter functions together with the 'Rate Per User' parameter (see above).

'Reserved Capacity'

reservation

[SBCAdmissionRule_Reservation]

Defines the guaranteed (minimum) call capacity.

The default is 0 (i.e., no reserved capacity).

If you configure reserved call capacity for an SRD and each of its associated IP Groups, the SRD's reserved call capacity must be greater or equal to the summation of the reserved call capacity of all these IP Groups. In other words, the SRD serves as the "parent" reserved call capacity. If the SRD's reserved call capacity is greater, the extra call capacity can be used as a shared pool between the IP Groups for unreserved calls when they exceed their reserved capacity. For example, assume that the reserved capacity for an SRD and its associated IP Groups are as follows:

■ SRD reserved call capacity: 40
■ IP Group ID 1 reserved call capacity: 10
■ IP Group ID 2 reserved call capacity: 20

In this setup, the SRD offers a shared pool for unreserved call capacity of 10 [i.e., 40 – (10 + 20)]. If IP Group ID 1 needs to handle 15 calls, it is guaranteed 10 calls and the remaining 5 is provided from the SRD's shared pool. If the SDR's shared pool is currently empty and resources for new calls are required, the quota is taken from the device's total capacity, if available. For example, if IP Group ID 1 needs to handle 21 calls, it's guaranteed 10, the SRD's shared pool provides another 10, and the last call is provided from the device's total call capacity support (e.g., of 200).

Note:

■ The parameter is not related to the rate-limiting algorithms.
■ Reserved call capacity is applicable only to IP Groups and SRDs.
■ Reserved call capacity is applicable only to INVITE and SUBSCRIBE messages.
■ Reserved call capacity must be less than the maximum capacity (limit) configured for the CAC rule (see the 'Limit' parameter).
■ The total reserved call capacity configured for all CAC rules must be within the device's total call capacity support.